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Svsteme d'acces a un reseau adapte pour la mise en osuvre d'un procede 
a signature simplifiee, et serveur pour sa realisation, 

Uinvention conceme un syst§me d'acces § un reseau adapte pour la 
5 mise en cBuvre d'un procede a signature simplifiee, et un serveur pour sa 
realisation. 

Plus precisement, Tinvention conceme un systeme comportant : 

- au moins un poste d'utilisateur equlpe d'un navigateur internet, 

- un serveur proxy par lequel passent tous les flux d'informations 
10 echanges entre le ou chaque poste d'utllisateur et ledit reseau, 

- plusieurs foumisseurs de services raccord§s audit reseau, 
chaque fournisseur de services etant apte d Smettre una requSte 
d'authentlfication vers le poste de Tutilisateur qui le contacte pour identifier et/ou 
authentifier cet utilisateur avant de lui foumir des sen/ices personnaiises et/ou 

15 securis6s, la reponse S foumir par un meme utilisateur d cette requete 
d'authentification pouvant etre differente en fonction du fournisseur de services 
contacts, 

- au moins un serveur d'authentrfication propre ^ memoriser au 
moins une Information d'authentlflcatlon pour chaque utilisateur et a transmettre 

20 en reponse a une requete d'authentlficatlon une reponse d'authentification 
contenant une information d'authentification fonction ^ la fois du fournisseur de 
services ayant §mis la requ§te d'authentification, et de I'identitS de {'utilisateur 
ayant contacts ce fournisseur de services, et 

- un module a signature simplifiee apte a traiter automatiquement 
25 en lieu et place du ou de chaque poste d'utilisateur les requetes 

d'authentification emises par les foumisseurs de services contact^s, ce module 
^tant apte pour chaque utilisateur : 

- ^ dinger les requetes d'authentification vers le serveur 
d'auttientification approprte, et 
30 - ^ retransmettre au fournisseur de services la reponse 

d'authentification correspondante transmise par le serveur d'authentification 
approprie. 
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Ces syst^mes pemnettent de mettre en oeuvre un proc^de a 
signature simpliflee plus connu sous les tennes de proc§d6 SSO C'Slngle Sign 
On" ou "Simplified Sign On"). Des renseignements plus precis sur un exemple 
de proced6 SSO peuvent §tre obtenus d la lecture des recommandations 
5 d§finies par le consortium d'entreprises appel6 Liberty Alliance, dont le but est 
Is developpement des transactions sur Internet. Ces recommandations peuvent 
par exemple, etre obtenues a partir du site Intemet http://w\ww.projectliberty.org. 

Les proc6d6s SSO visent a simplifier I'identification et/ou 
Tauthentification d'un utilisateur sur la toile d'araign§e mondiale plus connue 
10 sous les termes de WEB (World Wide Web). Dans la suite de cette description, 
la toile d'araignee mondiale sera simplement d§sign6e par le terme reseau 
intemet 

Les prDc6d6s SSO et notamment ceux conformes aux 
recommandations de Liberty Alliance, imptementent le module a signature 

15 simplifi§e dans le serveur proxy. Toutefois, cette solution pr6sente 
I'lnconv§nient qu'elle implique des modifications substantielles des serveurs 
proxy existants et qu'elle suppose une augmentation des traitements ^ realiser 
par les serveurs proxy existants. 

L'invention vise a rem§dier a cet inconvenient en proposant un 

20 systeme d'acces d un reseau a commutation de paquets adapts pour la mise 
en oeuvre d'un proced6 SSO dans lequel les modifications ^ apporter au 
serveur proxy sont mineures et les consequences sur la charge ^ traiter sont 
mineures. 

L'invention a done pour objet un syst§me tel que d^crlt ci-dessus, 
25 caract6ris6 en ce qu'il comporte uri serveur suppl6mentaire ind§pendant du 
serveur proxy, le module d signature simplifiSe 6tant imptemente dans ce 
serveur supptementaire, et en ce que le serveur proxy est equips d'une 
interface pemnettant de raccorder le sen^eur supplSmentaire et de transmettre 
au moins les requites d'authentification emises par les foumisseurs de services 
30 contactes audit serveur supplementaire pour traitement de ces requ6t^ par le 
module k signature simplifiee. 

Suivant d'autres caracteristiques du systeme conforme a l'invention, 
celui-ci se caracterise en ce que : 
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- le module a signature simplifiee comporte un sous-module propre a 
identifier Tutilisateur a partir de son adresse reseau et ^ ajouter un identrfioateur 
de rutllisateur aux requetes d'authentrfication dirigees vers les serveurs 
d'autheritificatlon ; 

5 - ladlte au nnoins une information d'authentificatlon m6morisee pour 

chaque utilisateur comprend une information sur un niveau d'authentification 
disponible pour cet utilisateur, en ce que chaque requete d'autlnentification 
emise par un fournisseur de services specifie des caracteristiques sur ie niveau 
d'autlientlfication requis par ce fournisseur de services pour pouvoir acceder 

10 aux services qu'il propose, en ce que le ou cliaque serveur d'authentification est 
apte a comparer les caracteristiques sur le niveau d'authentification requls 
specific par la requite d'authentification ^ rinformation sur le niveau 
d'authentification disponible, de mani^re a determiner si ie niveau 
d'authentification requis correspond au niveau d'authentiTication disponible pour 

15 cet utilisateur, et en ce que le ou chaque serveur d'authentification est apte a 
emettre vers Tutilisateur une requete d'authentification active propre a activer 
sur le poste de ('utilisateur un processus interactif d'identification et/ou 
d'authentification de I'utilisateur si le niveau d'authentification requis ne 
correspond pas au niveau d'authentification disponible ; 

20 - le serveur supplementaire comporte un sous-module propre a 

dinger la reponse de Tutilisateur aux requetes d'authentification active vers le 
serveur d'authentification qui I'a emise ; 

- le serveur supplementaire comporte un sous module propre a 
diriger la requete d'authentification active vers ie poste de Tutilisateur ; 

25 - le module a signature simplifiee comporte un sous-module capable 

d'ajouter aux requStes transmises par le poste d'utiiisateur vers un fournisseur 
de services un signal d'identification de service a signature simplifiee en 
reponse auquel le foumisseur de services Smet la requete d'authentification ; 

- le serveur supplementaire et le serveur proxy sont aptes a 
30 communiquer I'un avec I'autre en mettant en oeuvre un protocols de transfer! de 

flux HTTP (Hyper Text Transfer Protocol) ; 
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- le protocole de transfert de flux HTTP est le protocole iCAP 
(Internet Content Adaptation Protocol) ou le protocole OOP (OPES Call Out 
Protocol). 

- le serveur supplementaire est uniquement apte d communiquer 
S avec les foumisseurs de services par I'intermediaire du protocole de transfert 

de flux HTTP mis en oeuvre entre lui et le sen/eul- proxy ; 

- le serveur supplementaire implements egalement un serveur et/ou 
un client HTTP (Hyper Text Transfer Protocol) pour communiquer directement 
avec le ou chaque fournisseur de services et/ou le ou chaque serveur 

10 d'authentification uniquement k I'aide du protocole HTTP ; 

- il comporte un fournisseur d'acces audit rdseau auquel dott se 
connecter le ou chaque poste d'ulilisateur pour pouvoir acceder audit reseau, 

^ ce fournisseur d'acces 6tant ^quip§ du serveur proxy ; 

- ledit reseau est la tolle d'araignde mondiaie. 

15 L'invention sera mieux comprise d la lecture de la description qui va 

suivre donn§e uniquement ^ titre d'exemple et faite en se referent aux dessins 
sur lesquels : 

- la figure 1 est une illustration sch6matique de I'architecture d'un 
systeme conforms a l'invention, 

20 - la figure 2 est un organigramme d'un proced§ ^ signature simplifiee 

mis en oeuvre dans le systeme de la figure 1 , et 

- les figures 3 et 4 sent des illustrations schematiques de la 
circulation des flux d'infomiations entre les differents 6quipements du systeme 
de la figure 1. 

25 La figure 1 repr§sente un systdme, d^signd par la refSrence generale 

2, d'acces a un reseau 4 d commutation de paquets adaptd pour la mise en 
oeuvre d'un proc6d§ SSO conforme aux recommandations dSfinies par Liberty 
Alliance. 

Les recommandations §tablles par Liberty Alliance d^finissent 
30 Torganisation et les fonctionnalites des differents equipements ou groupes 
d'equipements du systeme 2 avec une precision suffisante pour que I'homme 
du metier a la lecture de ces recommandations puisse fabriquer ses 
equipements. Ces recommandations ne decrivent pas la realisation detaillee de 
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chacun de ces 6quipements. Par consequent, dans ia suite de la description, on 
ne decrira de fa9on d^taiii^ que ie bloc d'equlpement represents par un 
rectangle en polntill§ sur la figure 1, les autres 6quipements du systSme 2 6tant 
realises de fa^on conventionnelle d partir des recommandations de Liberty 
5 Alliance. 

Le syst^me 2 sera ici d6crit dans Ie cas particulier oCi Ie rSseau 4 est 
Ie reseau internet. 

Le systems 2 comporte de nombreux postes d'utilisateurs ayant des 
fonctionnairtes similaires les unes aux autres ainsi que plusieurs foumisseurs 
10 d'accds internet, ayant egalement des fonctionnalites similaires les unes aux 
autres. Ici pour simplifier nilustration de la figure 1, seul un poste d'utiiisateur 10 
et un foumisseur d'acc^ 12 ont StS representes. 

Le poste 10 est apte a naviguer sur le reseau 4. A cet effet, il est 
fomn6, par exennple, d'un ordinateur convenlionnel 14 Squipe d'un ^cran et d'un 
15 clavier ainsi que d'un navigateur internet 16 plus connu sous le terme anglais 
de "browser". 

Le systeme 2 comporte 6galement de nombreux syst6mes 
foumisseurs de services ainsi que plusieurs serveurs d'authentification. Id, 
seuls deux systSmes foumisseurs de services 20, 22, d6sign§s foumisseurs, 
20 ainsi que deux serveurs d'authentification 24, 26 sont representes sur la figure 
1 pour simplifier I'illustration. 

Les foumisseurs de sen/ices 20, 22 sont destines ^ rend re des 
services a I'utilisateur du poste 1 0. 

Par exemple, ici, le foumisseur 20 est un sen^eur informatlque propre 
25 d etablir des fiches de paye en fonction des infomnations qui iui sont 
communlqu6es par I'utilisateur du poste 10. Pour cela, le serveur 20 comporte 
un module 32 propre d identifier et d authentifier Tutilisateur du poste 10 de 
mani6re a personnaliser et ^ sScuriser ie service qu'il rend a cet utilisateur. Plus 
precisement, le foumisseur 20 est associd d une m§moire 30 dans iaqueile est 
30 enregistree une liste 34 de serveurs d'authentification connus du foumisseur 20 
ainsi qu'un niveau 36 d'authentification requis par ce foumisseur. 

La liste 34 comporte des identificateurs des serveurs 
d'authentification contenant des informations d'authentification propres a 
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identifier et autiientifier un utilisateur aupr§s de ce foumisseur de services. Une 
telle information est, par exemple, un niveau d'authentrfication disponible 
actueliement pour un utilisateur donn6. 

Le niveau d'authent'rfication enregistr6 dans la m^moire 30 definit la 

5 quality de I'authentificatlon requise par le foumisseur 20. Dans le systeme 2, ^ 
titre d'exemple, cliaque niveau d'authentification peut prendre I'une quelconque 
des valeurs enti^res comprises entre "1" et "5". Plus la valeur du niveau 
• d'authentification est petite, plus la qualit§ de I'authentification est faible. Ici, a 
titre d'exemple, le niveau d'authentification 36 est egal d "2". 

10 Les fbnctions realis§es par.le module 32 sont decrites plus en detail 

en regard des figures 3 et 4 et I'intSrSt de la liste 34 ainsi que du niveau 
d'authentification apparaTtra S la lecture de la suite de cette description. On 
mentionnera ici simplement le feit que le module 32 est capable d'emettre une 
requite d'authentification HTTP Incluse dans une reponse HTTP pour 

15 authentifier I'utilisateur vers ie poste 1 0 de cet utilisateur. 

Le foumisseur 22 pemiet, par exemple. A I'utilisateur du poste 10 de 
g^rer ^ distance ses comptes bancaires et d'efFectuer 6galement des 
transactions bancaires. Le foumisseur 22 comporte les m§mes elements que 
ceux decrits en regard du foumisseur 20 a I'exception du fait que le niveau 

20 d'authentification 36 est remplac6 par un niveau d'authentification 38 egal a "4". 

Les serveurs d'authentification 24 et 26 sont destines a repondre aux 
requetes d'authentification 6mises par les fournisseurs de services. A cet effet, 
les serveurs 24 et 26 sont associes chacun a une m§moire 40, 41 dans laquelle 
est enregistr6e pour chaque utilisateur connu de ce serveur, une information 

25 42, 43 d'authentification. Chaque information d'authentification contient le 
niveau d'authentification disponible pour I'utilisateur conrespondant. 

Chaque serveur d'authentification 24. 26 cornporte §galement un 
module 44 de contrdle d'accds. Ce module permet aux serveurs 24 et 26 
d'emettre une requSte d'.authentification active de maniere a interroger 

30 I'utilisateur du poste 10 pour que celul-ci foumisse un jeu d'informations 
pennettant de I'identifier et de I'authentifier avec un niveau d'authentification 
souhait6. Un jeu d'inforrhations est, par exemple. un identificateur de I'utilisateur 
et son mot de passe. 
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Ces serveurs d'authentification sont connus sous les termes anglais 
"Identity provider". 

Le foumisseur d'acces 12 est capable de remplir les fonctions 
classiques d'un foumisseur d'acces internet, c'est-d-dire notamment d'affecter 
S une adresse rSseau au poste 10 pour que celui-ci puisse naviguer sur le reseau 
4. 

A cet effet. ii comporte un serveur proxy HTTP (Hyper Text Transfer 
Protocol) et un serveur 52 de controle d'acces. Le protocole HTTP existant est 
un protocole de communication utilise pour les echanges de donnees entre des 

10 clients HTTP et des serveurs HTTP connus sous les termes de serveur web. Le 
serveur proxy est place en coupure de flux entre le poste 10 et le reseau 4, 
c'est-a-dire que Tensemble des flux d'informations echanges entre le navigateur 
16 du poste 10 et le reseau 4 passe par Tintermediaire du sen/eur proxy 50. 
Ainsi, le serveur proxy 50 voit passer Tensemble des requetes et des reponses 

15 HTTP §mises par le poste 10 ou vers le poste 1 0. 

Le serveur de controle d'acces 52 est capable d'identifier et 
d'authentifier Tutilisateur du poste 10 avant d'autoriser ce poste 10 a se 
connecter au reseau 4 et d naviguer sur celui-ci. Typiquement, Tutilisateu r du 
poste 10 s'identifie aupres du serveur 52 en fournissant un jeu d'informations 

20 contenant un identificateur connu sous le terme anglais de "login" et un mot de 
passe. Si Tutilisateur est correctement identifie et authentifie, c'est-a-dire que le 
jeu informations qu'il a foumi con^espond a un abonnement valide aupres de ce 
foumisseur d'acces, le serveur 52 affecte a cet utilisateur une adresse reseau, 
c'est-a-dire ici une adresse IP (Intemet Protocol) pour naviguer sur le reseau 4. 

25 Dans le cas contraire, le serveur 52 interdit toute connexion au r§seau 4. 

Le serveur 52 est egalement capable d'enregistrer dans une 
m§moire 54 ^ laquelle il est associ§ une liste 56 contenant pour chaque 
adresse IP afFectee a un utilisateur, I'identificateur de Tutilisateur correspondant. 
Cette ilste est mise d jour automatiquement par le serveur 52. 

30 Le foumisseur d'acces 12 comporte un serveur iCAP 60 (Intemet 

Content Adaptation Protocol) place a c6te du serveur 50 et raccorde a celui-ci 
par rintemiediaire d'une liaison filaire 62 ou d'un reseau local. Le protocole 
iCAP existant est normalise par I'organisme IETF (Internet Engineering Task 
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Force) pour la transformation systematique de contenus sur Internet, Ainsi, le 
serveur 60 et le serveur 50 sont capables de comnnuniquer Tun avec Tautre en 
mettant en oeuvre le protocole iCAP. Plus precisennent, le serveur 50 est apte a 
communiquer au serveur 60 des requStes ou des reponses HTTP pr^sentes 
5 dans les flux d'informations echanges entre le poste 10 et ie r^seau 4 et le 
sen^eur 60 est Sgalement capable de transmettre des requites ou des 
reponses HTTP apres les avoir modlfiees au serveur 50. 

De mani§re a innplementer un client iCAP dans le serveur proxy 50 
celui-ci est equipe d'une interface iCAP 64 comportant un connecteur 
10 permettant de le raccorder au serveur 60. 

L'interface 64 est ici configuree pour transmettre au serveur 60 
uniquement les requetes ou les reponses HTTP qui doivent Stre modifiees pour 
la mise en oeuvre du procede SSO. 

Le serveur 60 est equipe d'un module SSO 66 propre a prendre en 
15 charge tous les traitements specifiques requis par la mise en oeuvre du procede 
SSO. Ce module 66 comporte trois sous-modules 68, 70 et 72 conrespondant 
chacun a un service iCAP. Ces sous-modules seront decrits plus en detail en 
regard de chacune des figures 3 et 4. 

Le serveur 60 est associS ^ la mSmoire 54 qui contient 6galement 
20 une ilste 76 des serveurs d'authentificaiion connus par chaque utilisateur. Oette 
liste 76 regroupe pour chaque utilisateur, les identificateurs des differents 
serveurs d'authentlfication dans lesquels sont memorisees des inforrriatlons 
d'authentification pour cet utilisateur. 

Le serveur 60 implemente aussi un client HTTP. A cet effet, il est 
25 raccorde au reseau 4 par Tintermediaire d'un serveur proxy HTTP 
supplementaire 74 qui peut Stre independant et distinct du serveur proxy 50. 

L'ensemble des serveurs du systeme 2 sont realises a partlr de 
calculateurs Slectroniques conventionnels programmables aptes a executer des 
instructions enregistrees sur un support d'enregistrement d'informations. A cet 
30 effet, les memoires 30, 40, 41 et 54 comportent des instmctions pour 
rexecution du procede SSO des figures 2 a 4 lorsque lesdites instructions sont 
ex§cutees par ces calculateurs. 
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Le fonctionnement du systeme 2 va maintenant etre decrit en regard 
des figures 2 a 4. 

Initialement, lors d'une etape 90, un identificateur du serveur 24 est 
enregistr§ dans la liste 76 des serveurs d'authentification connus par 
5 Tutilisateur. 

Parallelement, lors d'une 6tape 92, les listes 34 des foumisseurs de 
services sont mises §i jour. 

Ensuite, Tutilisateur du poste 10 se connects, lors d'une etape 94, au 
reseau 4. Lors de cette etape, Tutilisateur saisit, lors d'une operation 96, un jeu 

10 d'informations permettant de Tidentifier et de rauthentifier aupres du serveur 52 . 

Une fois que Tutiiisateur 10 a ete identifie et authentifie, le serveur 
52, lors d'une operation 98, lui affecte une adresse IP et enregistre la relation 
entre cette adresse reseau et ridentificateur de cet utilisateur dans la liste 56. 

Ensuite, le serveur 52 informe, lors d'une operation 100, les 

IS dHferents serveurs d'authentification connus par cet utilisateur que celui-ci a 6te 
correctement identifie et authentifie. Cette identification et authentification 
r^alisee par le serveur 52 est ici associee a un niveau d'authentification egal a 
"2" de sorte que les serveurs d'authentification memorisent que le niveau 
d'authentification disponible est egal a "2". 

20 Une fois autoris§ ^ naviguer sur le reseau 4, Tutilisateur se connect©, 

par exemple, lors d'une etape 104. au foumisseur de services 20. Le module 32 
du fournisseur 20 emet alors en reponse, lors d'une operation 106, une requete 
d'authentification HTTP incluse dans une reponse HTTP a destination du poste 
10. Cette requSte est interceptee par le serveur proxy 50 puis traitee par le 

25 serveur iCAP 60 et enfin transmise jusqu'au serveur d'authentification 24. Cette 
requete d'authentification comporte le niveau d'authentification 36. Le serveur 
24 v^rifie, lors d'une etape 108, que le niveau d'authentification disponible pour 
cet utilisateur est au moins §gal ^ "2". Ici, le niveau d'authentification disponible 
etant 6gal a ceiui requis par le foumisseur 20, le serveur 24 transmet, lors d'une 

30 etape 110, une reponse d'authentification contenant un certificat 
d'authentification au foumisseur 20. Ce certificat informe le foumisseur 20 que 
le niveau d'authentification requis est disponible. 



wo 2005/034468 



PCT/FR2004/002272 



Le foumisseur 20 ayant regu le certificat propose alors, lors d'une 
etape 112, d cet utiiisateur un service personnalisS et / ou s§curis^ sans que 
rutilisateur ait besoin de s'identifier aupres du foumisseur 20. Par exemple. le 
foumisseur 20 lui propose {'impression d'une feuille de paye comportant son 
5 nom. 

Ensuite, toujours lors de ia m§me connexion, I'utilisateur 10 se 
connecte en 114 au foumisseur de sen/ices 22. Ce foumisseur 22 execute alors 
■'operation 106. 

Toutefois, contrairement au cas precedent, le sen/eur 
10 d'authentification 24 constate que le niveau d'authentification requis par le 
foumisseur 22 est superieur d celul actueliement disponible pour cet utiiisateur. 

Le module 44 de contrdle d'acc§s du serveur 24 precede alors d une 
§tape 120 d'authentification active lors de laquelle il intenroge i'utilisateur, de 
mani^re d identifier et ^.autiientifier celui-ci avec une quality d'autiientification 
15 con-espondant au niveau d'autiientification "4". Par exemple, le module 44 
demande d I'utilisateur de saisir des infonmations personnelles telles que sa 
date de naissance. 

Si I'utilisateur du poste 10 a ^t§ conBctement identifid et autlientifi^ 
avec un niveau d'authentification "4", le serveur 24 enreglstre le nouveau 
20 niveau d'authentification disponible dans sa m6moire 40 et procfede ^ I'^tape 
110. 

Ensuite, le foumisseur 22 propose lors d'une etape 122 un service 
personnalise et / ou securise ^ cet utiiisateur. 

Le proc§d^ ci-dessus d^crit dans le cas particuller des foumisseurs 
25 20, 22, est alors r§it§r6 au fur et d mesure que Tutiiisateur du poste 10 contacte 
de nouveaux foumisseurs de services. 

Ainsl, grSce d ce proc§d§, I'authentification de I'utilisateur est 
slmpiifiee puisque celu'i-ci ne doit s'identifier et s'authentifier que lors de la 
connexion au reseau 4 puis ensuite ^ chaque fois qu'il contacte un foumisseur 
30 de services exigeant un niveau d'authentification superieur d celul disponible. 
Ce precede pemnet done d'eviter d I'utilisateur de saisir, ^ chaque fois qu'il 
contacte un nouveau foumisseur de services, un jeu d'lnformations 
d'identiflcation et d'authentification correspondant a ce foumisseur de services. 
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Les flux d'informations ^changes entre les equipements du systeme 
2 lors des etapes 104 § 122 vont maintenant Stre decrits plus en details en 
regard des figures 3 et 4. 

Sur les figures 3 et 4 les blocs rectangulaires repr^sentent des 
5 equipements ou des listes memorisees deja decrites en regard de la figure 1 et 
portent done les memes references. Les fleches entre ces equipements 
representent a la fois ie sens de circulation des informations et les operations 
correspondantes. 

Initialement, Ie navigateur 16 du poste 10 envoie une requete HTTP 

10 vers Ie module 32 d'un fournisseur de services, par exemple Ie foumisseur 20. 
Cette requete est acheminee, lors d'une operation 130, jusqu'au serveur proxy 
50. L'interface 64 intercepte cette requete et la transmet, lors d'une operation 
132, au serveur 60 et plus pr6cis6ment au sous-module 68. Le sous-module 68 
ajoute un en-t§te d la requite HTTP indlquant que Ie systeme 2 supporte un 

15 precede SSO et retransmet, lors d'une operation 134 cette requete HTTP ainsi 
modifiee vers le serveur proxy 50. 

Le serveur proxy transmet alors la requete HTTP modifiee jusqu^au 
fournisseur de services lors d'une operation 136. 

Le module 32 du foumisseur de services detecte la presence de Ten- 

20 tete ajoute par le sous-module 68 et, en reponse, envoie, lors d'une operation 
138, une requ§te d'authentrfication vers le navigateur 16. 

La requete d*authentification est, par exemple, confomie au 
protocole SOAP (Single Object Access Protocol) normalise par rorganisme 
W3C (World Wide Web Consortium). \ 

25 Cette requSte d'authentlfication comporte notamment un identrTiant 

du foumisseur de services, une copie de la iiste 34 de serveurs 
d'authentification connus, ie niveau d'authentification requis par ce foumisseur 
et, par exemple, une instruction connue sous les termes anglais "set cookie" 
destinee a enregistrer un identificateur de la requete d'authentification sur le 

30 poste 10 ou, en variante, directement un identifiant de la requete. 

L'interface 64 du serveur proxy 50 intercepte cette requete 
d'authentification et la dirige, lors d'une operation 140, vers le sous-module 70 
du serveur 60. 
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Le sous-module 70 compare, lors d'une operation 142, ia liste 34 
regue a la liste 56 pour s^lectionner le serveur d'authentification a contacter, 
par example, ici le serveur 24. S'il n'existe aucun serveur d'authentification 
commun d la liste 34 reQue et ^ la liste 56, le sous-module 70 envoie un 

5 message d'incompatibilit§ au foumlsseur de services ayant Smis la requ§te 
d'authentification. Ce message d'incompatlbilit§ comporte I'ldentificateur de ia 
requete d'authentification, de maniere a ce que le module 32 puisse reller cette 
reponse a ia requ§te d'authentification correspondante. L'identificateur de ia 
requ§te d'authentification est, par exemple, celui contenu dans I'instruction "set 

10 cookie". 

Ensuite, le sous-module 70 d^tennine, lore d'une operation 144, 
I'identite de I'utilisateur du poste 10 en comparant I'adresse r^seau du poste 10 
d la liste 76. Cette adresse aura ^t^ fbumie par le serveur proxy 50 au sous- 
module 70 lors de I'operation 140 par I'interm^diaire d'un champ de I'en-tete 
15 HTTP. 

Une fois I'utilisateur identifie, le sous-module 70 procede a une 
operation 148 de transmission de la requete d'authentification regue associ^ d 
l'identificateur de I'utilisateur obtenu lors de l'op6ration 144, au serveur 
d'authentification selectionne lors de {'operation 142. 
20 Le serveur 24 compare, lors d'une operation 150, le niveau 

d'authentification disponibie pour I'utilisateur d celui requis par le foumisseur de 
services. 

Dans le cas oCi le niveau d'authentification requis est sup^rieur a 
celui actuellement enregistr§ par le serveur 24, celui-ci procede comme decrit 
25 en regard de la figure 4. 

Dans le cas contraire, le serveur 24 envoie lors d'une operation 152, 
une rSponse d'authentification au serveur 60. 

Le sous-module 70 regoit la reponse d'authentification et la transmet, 
lors d'une operation 156, vers le foumisseur de services par i'intennediaire du 
30 serveur proxy 74 et en utiiisant le protocole HTTP. Cette reponse 
d'authentification comporte si n§cessaire un identificateur de I'utilisateur. 

Le foumisseur de services repond k cette reponse d'authentification 
en transmettant vers le serveur 60, lors d'une operation 158, par exemple, une 
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page d*accueil personnalisee. Cette reponse est transmise par rintermediaire 
du serveur proxy 74 au serveur 60 en utiiisant le protocole HTTP. 

Le sous-module 70 redirige, lors d'une operation 160, cette reponse 
vers le serveur proxy 50 en utiiisant le protocole iCAP qui la redirige, a son tour, 

5 lors d'une operation 162, vers le navigateur 16 en utilisant-le protocole HTTP. 

Ainsi, une page d'accueil personnalis6e s^affiche sur le navigateur 16 
de Tutilisateur du poste 10 sans meme que cet utilisateur ait eu besoin de 
s'identifier aupres, par exemple, du fournisseur 20. 

La figure 4 represente la circulation des informations entre les 

10 dIfFerents equlpemente du systeme 2 dans ie cas particulier oCi le niveau 
d'authentification requis par le fournisseur de services contaote est sup^rieur a 
celui actuellement m§moris§ dans la m§moire 40 du serveur 24. Sur cette 
figure, les Squipements et les operations d6ja decrits en regard des figures 1 et 
3 portent les memos references et les nouvelles operations sont representees 

15 en traits gras. 

Lors de Toperation 150, le serveur 24 a etabli que le niveau 
d'authentification requis est superieur a celui actuellement disponible pour 
Tutilisateur. Par consequent, 11 precede a une operation 180 lors de laquelle le 
module 44 transmet une requete d'authentification active vers le serveur 60 

20 contenue dans une reponse HTTP et en utiiisant le protocole HTTP. La requete 
d'authentification active est destinee a activer sur le navigateur 16 un processus 
d'authentification interactlf. A cet effet, cette requdte comporte ici un formulaire 
a completer par Tutilisateur. 

Le sous-module 70 retransmet lors d'une operation 182, cette 

25 requSte d'authentification active vers le serveur proxy 50 en utiiisant ie 
protocole iCAP, puis le serveur proxy 50 la retransmet, lors d'une operation 
184, vers ie navigateur 16 en utiiisant le protocole HTTP. Le navigateur 16 
affiche le formulaire qui permet a Tutilisateur de s'identifier et de s'authentifier 
avec un niveau d'authentification superieur, par exemple, egal a "4" dans le cas 

30 du fournisseur de services 22. Une fois que le formulaire a ete complete, le 
navigateur 16 envoie, lors d*une operation 186, la reponse dans une requete 
HTTP. Cette reponse est interceptee par Tinterface 64 du serveur 50 et 
transmise, lors d'une operation 188, au sous-module 72 en utiiisant le protocole 
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iCAP. Le sous-module 72 retransmet alors, lors d'une operation 190, ia r§ponse 
de Tutllisateur en utillsant le protocole HTTP au serveur 24. Si ie formulaire a 
correctement 6te complete par rutillsateur, c'est-a-dire que le jeu d'Informations 
d'identification et d'authentlfication est correcte, le serveur 24 memorise, lors 
5 d'une operation 192, le nouveau niveau d'authentification disponible dans la 
memoire 40 et procede ensuite a ('operation 152. Les operations suivantes sont 
identiques a celles decrites en regard de la figure 2 a Texception du fait que ies 
operations 152, 156. 158 et 160 font intervenir le sous-module 72 a la place du 
sous-module 70. 

10 La plupart des serveurs proxy existant comportent deja une interface 

iCAP. Ainsi, le syst§me de la figure 2 simplifie la mise en oeuvre du precede 
SSO puisque la seule modification a apporter au serveur proxy consiste a le 
configurer de maniere ^ ce que Tinterface iCAP intercepte les requStes HTTP 
necessaires a ia mise en oeuvre de ce procSdd. 

15 La circulation des flux d'Informations entre les differents §l6ments du 

systeme 2 a et§ decrite dans le cas partlculier ou le serveur iCAP 60 
communique directement en utilisant le protocole HTTP avec le ou les 
fournisseurs de services lors des operations 156 et 158. En variante, le sen^eur 
ICAP communique avec les fournisseurs de services uniquement par 

20 rintermediaire du protocole iCAP. Par exemple, dans cette variante, les 
requ§tes HTTP emises a destination du foumisseur de services lors de 
roperation. 156 sont d'abord transmises par le serveur 60 jusqu'au sen^eur 
proxy 50 en utilisant le protocole iCAP puis le serveur proxy 50 transmet ces 
requetes au foumisseur de services en utilisant le protocole HTTP. La reponse 

25 HTTP emise par le foumisseur de sen^ices lors de I'op6ration 158 suit le chemin 
inverse de la requete ^mlse lors de Toperation 156. Dans cette variante, ie 
serveur 60 ne communique jamais directement avec les foumisseurs de 
services de sorte que ceux-ci ne sont pas au courant de Texistence du serveur 
60. Uutilisation du serveur 60 est alors totalement transparente pour ces 

30 foumisseurs de services. Cette variante presents Tavantage que du point de 
vue du foumisseur de services, tous les echanges dinformations se font entre 
lui et rutillsateur sans avoir connaissance de I'existence du serveur 60. Cette 
variante presente egalement Tavantage que les requetes HTTP emises et 



wo 2005/034468 



PCT/FR2004/002272 



regues lors des operations 156 et 158 sont directemerrt echangSes avec le 
serveur proxy 50 et non plus par rintermediaire du sous-module 70 ce qui 
accSl^re ie traltement de ces operations. 

Les sous-modules 68 d 72 ont ete d§crits dans le cas particulier oil 
5 lis sont tous implementes dans le meme serveur iCAP 60. En variante, ces 
sous-modules sont chacun implementes dans un serveur iCAP independent 
des autres. 

Ici, I'interface 64 est configuree pour n'intercepter que les requites 
HTTP qui dolvent §tre traitees par ie serveur ICAP. En variante, I'interface 64 

10 est configuree pour rediriger tous ies flux d'informations HTTP vers le serveur 
ICAP et le serveur iCAP implemente un module de filtrage propre S envoyer au 
module de traitement 66 uniquement ies requ§tes HTTP qui dolvent etre 
traitees par ce module. Ainsi, dans cette variante, I'interception des requites 
HTTP n'est pas r6alis6e par le serveur proxy 50 mais par le serveur ICAP. 

15 Le systeme 2 a ete represents dans le cas particulier oil les serveurs 

d'auttientification sont raccordes au foumisseur d'acces intemet par 
rintemriediaire du reseau 4. En variante, au moins I'un de ces serveurs 
d'authentification est loge chez le foumisseur d'acces internet et raccorde a 
celui-ci par rintermediaire d'un reseau local independent du reseau 4. Ce mode 

20 de mise en ceuvre avantageux lui permettra de beneficier de toutes les 
identifications / autlientifications realisees par le foumisseur d'acces et qui ne 
pounBlent Stre partagees avec des foumisseurs d'authentification externes pour 
des raisons de securite; 

De m§me, en variante, ie serveur iCAP est raccorde au serv/eur 

25 proxy 50 par I'intermediaire d'un reseau grande distance et non plus par 
rintermediaire d'une liaison ou d'un reseau local. 

Le systeme 2 a ete decrit dans ie cas particulier oCi la premiere 
authentification de cliaque utilisateur est realisee par le foumisseur d'acces 
intemet 12. En variante, cette premiere autlientification n'est plus realisee par le 

30 foumisseur d'acces intemet 12 mais, par exemple, par le premier foumisseur de 
services contacte par I'utiiisateur. 

^identification et I'authentification de I'utiiisateur ont ete decrites 
dans le cas particulier oil celle-ci se fait e partir d'un tenninal 10 equip6 d'un 
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ecran et d'un clavier ce qui permet de saisir un jeu d'informations d'identification 
et d'autjientification. En variante, la premiere identification et authentificatibn de 
Tutilisateur est realisee autdmatiquement par exemple, en identifiant le terminal 
utilise par cet utilisateur. Plus pr§cisement, lorsque ie terminal 10 est rennplac§ 

5 par un teleplione mobile, Tidentificatlon et Tauthentification de rutilisateur se font 
automatiquement en procedant a racquisition du numero de telephone du 
terminal. Dans ce cas, rauthentification est dite transparente. 

Le systeme 2 a 6gaiement ete d^crit dans le cas particulier ou les 
serveurs d'authentification memorisent uniquement le niveau d'authentification 

10 disponible pour chaque utilisateur ce qui renforce la securite du systeme 
puisqu'il n*est pas desirable que I'ensemble des mots de passe et autres 
infomriations secretes de rutilisateur soient enregistr§s dans un meme lieu. 
Toutefois, en variante, ces serveurs d'authentification m§morisent 6galement 
en tant qu'infomriations d'authentification le ou les jeux d'informations 

15 d'identification et d'authentification que chaque utilisateur est susceptible 
d'utiliser pour s'identifier et s'authentifier auprds de chaque fournisseur de 
services. Ainsi, dans cette variante, la reponse d'authentification comporte le 
jeu d'informations d'identification et d'authentification a transmettre au 
fournisseur de services pour que celui-ci identifie et authentifie rutilisateur. Ce 

20 jeu d'infonnations d'identification et d'authentification est transmis au 
foumisseur de services de fagon similaire a ce qui a ete decrit pour le certificat 
d'authenfrfication. 

Le systeme 2 a ete decrit dans le cas particulier oCi la requete 
d'authentification emise par chaque foumisseur de services comporte un niveau 

25 d'authentification. En variante, la requ§te d'authentification emise par I'un des 
foumisseurs de services ne comporte pas de niveau d'authentification. Dans 
cette variante, en reponse a cette requete d'authentification, le serveur 
d'authentification contacte foumit, en reponse, un certificat d'authentification 
indiquant simplement que rutilisateur a ete authentifie. Ainsi, dans cette 

30 variante, rutilisateur aura acces aux services du foumisseur de services a partir 
du moment ou il a ete authentifie au moins une fois et ceci quel que soit le 
niveau de cette authentification. 
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Le systeme 2 a ete decrit dans le cas particulier ou le reseau 4 est le 
reseau internet. Toutefois en vaiiante, ce reseau 4 est un reseau de 
transmission d'informations quelconque tel qu'un reseau local, un rSsesu a 
commutation de paquets quelconque ou un reseau a commutation de circuits. 
5 Le systeme 2 a ete decrit dans le cas particulier ou les serveurs 

d'autlientification sont aptes a emettre des requetes d'autlientification actives 
lorsque ceux-ci ne disposent pas d'une authentification satisfaisante pour 
Tutilisateur. En variante, les serveurs d'authentification ne sont pas aptes a 
emettre ces requdtes d'authentification actives. Des lors, dans cette variante, 

10 lorsqu'un serveur d'authentification est contacte alors qu'il ne poss^de, par 
example, aucune information d'authentification sur Tutiiisateur, il est apte ^ 
emettre un message d'erreur d la place d'une requ§te d'authentification active. 

Finalement, le systeme 2 a ete dScrit dans le cas particulier ou le 
protocole de transfer! de flux HTTP est le protocole ICAP. En variante, le 

15 protocole iCAP peut §tre remplace par tout autre protocole de transfert de flux 
HTTP tel que par exemple le protocole OCP (OPES Call Out Protocol) avec 
OPES (Open Pluggable Edge Services). 

Le systeme 2 a et§ d6fini en faisant reference aux recommandations 
§tablies par Liberty Alliance. Toutefois, Tinvention revendiquee n'est pas limitee 

20 aux systemes et aux precedes conformes aux recommandations de Liberty 
Alliance et s'applique a tout systeme ou precede presentant des fonctionnalites 
similaires a celles decrites ici. 
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REVENDICATIONS 

1. Systeme d'acces a un reseau (4) a commutation de paquets 
5 adapte pour la mise en oeuvre d*un precede a signature simpiifiee, ce systeme 
comportant : 

- un serveur proxy (50) par lequel passant tous les flux 
d'informations echang^s entre un utiiisateur et ledit r§seau, 

- plusieurs fournisseurs (20, 22) de services raccordes audit 
10 reseau (4), cheque foumisseur de services §tant apte a Smettre une requSte 

d'authentificatlon vers Tutilisateur qui le contacte pour identifier et/ou authentifier 
cet utiiisateur avant de lui fournir des services personnalls6s et/ou securisSs, la 
reponse d fournir par un mSme utiiisateur a cette requSte d'authentification 
pouvant etre differente en fonction du foumisseur de services contacte, 

15 - au moins un serveur d'authentification (24, 26) propre a 

memoriser au moins une information d'authentification pour chaque utiiisateur 
et a transmettre en reponse a une requete d'authentification une reponse 
d'authentification contenant une information d'authentification fonction a la fois 
du foumisseur de services ayant ^mis ia requSte d'autlientification, et de 

20 ridentite de I'utiiisateur ayant contacte ce foumisseur de services, et 

- un module (66) d signature simpirfiee apte a traiter 
automatiquement en lieu et place de I'utiiisateur les requStes d'authentification 
emises par les fournisseurs de services contactes, ce module etant apte pour 
chaque utiiisateur : 

25 - a diriger les requetes d'authentification vers le sen/eur 

d'authentification (24, 26) approprie, et 

- a retransmettre au foumisseur de services la reponse 
d'authentification correspondan^ transmise par le serveur d'authentification 
approprie, 

30 caracterise en ce qu'il comporte un serveur supplementaire (60) 

independant du serveur proxy (50), le module a signature simplifiee (66) etant 
implemente dans ce serveur supplementaire (60), et en ce que le serveur proxy 
(50) est equips d'une interface (64) permettant de le raccorder au serveur 
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supplementaire (60) et de transmettre au moins ies requetes d'authentification 
emises par les foumisseurs de services contactes audit serveur supplementaire 
(60) pour traitement de ces requetes par le module ^ signature simpiifiee (66). 

2. Systdme selon la revendication 1, caracterise en ce que le module 
5 a signature simpiifiee (66) comporte un sous-module (70) propre a identifier 

rutiiisateur a partir de son adresse reseau et a ajouter un identificateur de 
rutilisateur aux requetes d'authentification dirigees vers les serveurs 
d'authentification. 

3. Systeme selon Tune quelconque des revendlcations precedentes, 
10 caracterise en ce que iadite au moins une Information d'authentification 

memorisee pour chaque utiiisaieur comprend une information sur un niveau 
d'authentification disponible pour cet utilisateur, en ce que chaque requete 
d'authentification §mise par un foumisseur de services (20, 22) sp§cifie des 
caract§ristiques sur le niveau d'authentification requis par ce fournisseur de 

IS services pour pouvoir acceder aux services qu'il propose, en ce que le ou 
chaque serveur d'authentification (24, 26) est apte ^ comparer les 
caracteristiques sur le niveau d'authentification requis specifie par la requete 
d'authentification a Tinformation sur le niveau d'authentification disponible, de 
maniere a detemriiner si le niveau d'authentification requis correspond au 

20 niveau d'authentification disponible pour cet utilisateur, et en ce que le ou 
chaque serveur d'authentification (24, 26) est apte a emettre vers Tutilisateur 
une requSte d'authentification active propre ^ activer un processus interact'if 
d'identification et/ou d'authentification de Tutiiisateur si le niveau 
d'autiienfification requis ne correspond pas au niveau d'authentification 

25 disponible. 

4. Systdme selon la revendication 3, caracterise en ce que ie serveur 
supplementaire (60) comporte un sous-module (72) propre a diriger la reponse 
de rutilisateur aux requetes d'authentification active vers ie serveur 
d'authentification qui i'a emise. 

30 5. Systeme selon la revendication 3 ou 4 caracterise en ce que le 

sen/eur supplementaire comporte un sous module (70) propre a diriger la 
requete d'authentification active vers rutilisateur. 
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6. Systeme selon Tune quelconque des revendications precedentes, 
caract6ris§ en ce que le module ^ signature simplrfiee (66) comporte un sous- 
module (68) capable d'ajouter aux requfites transmises par I'utilisateur vers un 
foumisseur de services un signal d'identification de service a signature 

5 simplifiee en reponse auquel le fournisseur de services emet la requete 
d'authentification. 

7. Systeme selon Tune quelconque des revendications precedentes, 
caracterise en ce que le serveur supplementaire (60) et le serveur proxy (50) 
sent aptes S communiquer Tun avec I 'autre en mettant en oeuvre un protocole 

10 de transfer! de flux HTTP (Hyper Text Transfer Protocol). 

8. Systeme selon la revendication 7, caracterise en ce que le 
protocole de transfert de flux HTTP est le protocole iCAP (Internet Content 
Adaptation Protocol) ou le protocole OCP (OPES Call Out Protocol). 

9. Systeme selon la revendication 7 ou 8, caract6ris6 en ce que le 
15 serveur supplementaire (60) est uniquement apte d communiquer avec les 

foumisseurs de services par Tintermediaire du protocole de transfert de flux 
HTTP mis en oeuvre entre lui et le serveur proxy (50). 

10. Systeme seion Tune quelconque des revendications 1 a 8, 
caracterise en ce que le serveur supplementaire (60) implemente egalement un 

20 serveur et/ou un client HTTP (Hyper Text Transfer Protocol) pour communiquer 
directement avec le ou cheque foumisseur de services et/ou le ou cheque 
serveur d'authentification uniquement S I'aide du protocole HTTP. 

11. Systeme selon Tune quelconque des revendications 
precedentes, caractdrisd en ce qu'li comporte un foumisseur d'acces (12) audit 

25 reseau (4) auquel doit se connecter Tutilisateur pour pouvoir acceder audit 
reseau, ce foumisseur d'acces §tant §quip§ du serveur proxy (50). 

12. Systeme selon Tune quelconque des revendications 
precedentes, caracterise en ce que led'rt reseau est la telle d'araignee mondiale. 

13. Serveur supplementaire apte ^ etre mis en oeuvre dans un 
30 systeme conforme k Tune quelconque des revendications precedentes, 

caracterise en ce qu'll comporte le module a signature simplifiee (66) apte a 
traiter automatiquement en lieu et place de Futilisateur les requetes 
d'authentification emises par le ou chaque foumisseur de services contacte, et 
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est apte d communiquer avec un serveur proxy (50) pour recevoir au moins les 
requStes d'authentification ^mises par les foumisseurs de services. 
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